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Abstract 


2. RCS 


The design and development of a Closed-Loop 
System to study and evaluate the performance of the 
Honeywell Recoverable Computer System (RCS) in 
electromagnetic environments (EME) is presented. The 
development of a Windows-based software package to 
handle the time-critical communication of data and 
commands between the RCS and flight simulation code in 
real-time, while meeting the stringent hard deadlines is also 
submitted. The performance results of the RCS and 
characteristics of its upset recovery scheme while 
exercising flight control laws under ideal conditions as well 
as in the presence of electromagnetic fields are also 
discussed. 


1. Introduction 

The problem of verifying the integrity of control 
computers in adverse as well as nominal operating 
environments is a key issue in the development, validation, 
certification, and operation of critical control systems for 
advanced aircraft. An adverse operating environment of 
particular concern relative to validation and certification of 
critical systems is caused by electromagnetic disturbances. 
Sources of electromagnetic disturbances include lightning, 
High Intensity Radiated Fields (HIRF) caused by RF 
transmitters and radars, portable electronics devices carried 
onto the airplane, and electromagnetic incompatibilities of 
equipment installed on the aircraft [1]. 

“Soft faults in digital avionics have traditionally 
been manually corrected. More recently, architecture 
design measures for the automatic correction of soft faults 
have begun to be developed. It is perceived that significant 
benefits can be gained through soft fault protection 
measures designed into the basic system mechanization. 
Architecture designs with soft fault protection provide the 
ability to tolerate disruption of either input/output data or 
internal computation. Fault clearing and computation 
recovery must be rapid enough to be “transparent” relative 
to functional operation and flight deck effect.” [2] 


“An example of an architectural soft fault 
protection philosophy in the design of computing platforms 
is the Aircraft Information Management System (AIMS) 
used on Boeing 777 aircraft. All computing and I/O 
management resources are lock-step compared on a 
processor cycle-by-cycle basis. In this approach, if a soft or 
hard fault event occurs, the processor is interrupted and 
service handlers take control and no data can be exported.” 
[ 2 ] 

The first stage of a prototype computing platform 
for fast recovery from soft faults has been developed for 
NASA. This prototype includes patented technology for 
transparent soft fault recovery that had not been built or 
tested before. These concepts were implemented and 
integrated into the basic lock-step processing module of the 
AIMS architecture. This prototype was delivered to NASA 
for evaluation at the Fangley Research Center (FaRC) 
system integration facility. A general illustration of a 
computing platform with transparent recovery elements is 
depicted in Figure 1. 
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Figure 1. Rapid Recovery Upset Detection and 
Recovery Flow 

Such a platform is intended to provide soft fault recovery 
that would be virtually software independent and 







transparent to a system function. As shown in Figure 1, the 
rapid recovery concept involves protecting and recovering 
the significant state variables of a system function. An 
aircraft autoland (arm, capture and track) function is being 
used for evaluation of the rapid recovery concept. Since 
this is the only function being implemented in the 
application program software, the partitioning portion of the 
platform SAFEbus technology was not employed. 
Communication with the LaRC host system integration 
facility is intended to be accomplished primarily through an 
optical 429 bus structure [2]. 


3. System Architecture 

The Closed-Loop architecture consists of the RCS, 
a VME-based optic card for conversion of data between 
electrical and optical signals, a flight simulation host 
processor, and a development environment. Since available 
PCs are very fast, powerful and relatively inexpensive, it 
seemed practical to attempt to perform the flight simulation 
operation, as well as collection and display of data on one 
PC, Figure 2. The challenge, therefore, was proving the 
feasibility of managing such system and real-time display 
of data on a PC. 
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Figure 2. PC-Based Systems. 


4. Software Development 

A real-time Graphical User Interface (GUI) 
package was developed for the Windows environment 
using C/C++ languages [3]. This modularized and user- 
friendly software consists of 429-interface and flight 
simulation code. It manages communication between the 
RCS and the flight simulation code and displays the data in 
real-time while meeting timing requirements of the RCS, 
Figure 3. In Figure 3, channel 2 shows the timing diagram 
of the RCS output and channel 3 is the timing diagram of 
the PC output. As is evident from this figure, after 
transmission of the data at the required time, the PC has 
ample time to store and display data before the next 
interval. 



Figure 3. RCS Communication Timing 
Diagram. 

This GUI software consists of many windows that 
depict Closed-Loop System activities in real-time. Roll and 
Aileron command (DELAC), Pitch and Elevator command 
(DELEC), and Altitude (ALT) and Radio Altitude (FIR- 
ALT) are displayed in three different windows to provide 
the user with visual correlation between the RCS inputs and 
their corresponding output commands. The lateral position 
(YCG), throttle (THROT), and yaw (YAW) are also 
displayed separately. In addition to an error-monitoring 
window, there are four other widows that display the 
discrete values reported by RCS. As a result, this software 
monitors all activities of the Closed-Loop System. This 
real-time monitoring capability is essential for testing the 
system in the presence of RF, Figure 4. 



Figure 4. RCS-Win Software. 


Through this user-friendly software, test 
conditions are specified and data are collected and recorded 
for future reference. Also, for software fault injection, the 
exact timing of the fault can be specified. 


4.1. Data Management 

The data along with the test conditions such as the 
RCS control flags, field strength range, and initial 
frequency are stored on the hard disk. Each file is 
approximately 2.4 Mbyte. Removable hard drives and a 
CD-ROM writer are used for archival storage. The 
collected data are in ARINC format [4] in order to 
minimize the storage requirements. The user interface 
software is then used to convert these data files to the 
desired format for post-test analysis purposes. 


5. Tests 

Tests for the RCS are being conducted in two 
phases. Phase one consists of testing under ideal conditions 
where HIRF is absent. Phase two consists of testing in the 
HIRF chambers and in the presence of RF. The specific 
goals are to characterize the RCS functionality and the RCS 
upset recovery scheme, to verify control laws and flight 
simulation integrity, and to assess RCS performance under 
various conditions. 

Phase one was necessary in order to resolve 
discrepancies in the Interface Control Document (ICD) and 
to debug the system as a whole. Completion of phase one 
also led to the detection of errors in the implementation of 
the flight control codes in the RCS [3]. 

Preliminary results of phase two of the tests are 
presented in the following sections of this paper. 


5.1. Test Environment 

The reverberation chambers of the HIRF facility at 
NASA FaRC provide the test environment. Within the test 
chamber are both transmitting and receiving antennas as 
well as any sensors that might be needed for a specific test. 
The components of the signal generation and measurement 
instrumentation consist of a synthesized sweeper for signal 
generation, a network analyzer, a spectrum analyzer, an 
oscilloscope, and a high-power amplifier [5, 6]. These 
devices are software controlled from within the HIRF 
Faboratory. The advantage of performing tests in mode- 
stirred chambers is that the equipment is subjected to fields 
at all angles of incidence simultaneously. The 
reverberation chambers within the HIRF Faboratory 
provide near-homogeneous randomized electromagnetic 
fields and make it possible to place the entire target unit in 
the test environment. 

During the test, the RCS is placed inside one of the 
mode-stirred chambers of the HIRF Faboratory and is 


interfaced to the flight simulation computer. Electrical 
isolation is achieved via fiber optic cables, Figure 5. 
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Figure 5. RCS Test Environment. 


While testing the RCS in the HIRF chamber, RF 
and/or field strength are gradually increased until a region 
of susceptibility is detected. In order to prevent damage to 
the RCS, RF is turned off for the remainder of the flight as 
soon as upset is detected. The test is then resumed with 
finer increments of frequencies and/or field strength in the 
vicinity of the susceptibility region. 


5.2. Test Approach 

Since the RCS is an expensive one-of-a-kind 
prototype the test approach was cautiously planned. The 
RCS was first tested with its shields on for a wide range of 
frequencies, namely 200 MHz to 1 GHz and 1GHz to 2 
GHz, and field strengths, 100 v/m to 800 v/m. The RCS 
proved rather resilient. Although a few regions of 
susceptibility were detected, the results were not repeatable. 

The RCS was then tested with the shields off for 
the frequency range of 100 MHz to 1 GHz and field 
strengths of 50 v/m to 250 v/m. 


5.3. Frequency Coverage 

In order to find all areas of susceptibility, a 
thorough coverage of all frequencies and field strengths is 
needed. Such comprehensive testing requires a great deal 
of time and resources. Since our goal is to characterize the 
RCS mechanisms, there is no need for such comprehensive 
coverage nor is there a need for a DO- 160 type test. All 
that is needed are a few areas of susceptibility. A heuristic 
approach was therefore adopted so that by decreasing the 
granularity of the frequency coverage, test time and cost 
could be drastically reduced. 

5.4. Emission Test 

Exploration of the radiated frequencies of the RCS 
revealed that there are three dominant frequencies 
emanating from the RCS. These frequencies are due to the 
internal clocks and oscillators for the optical I/O, RCS 
processors, and 429 card, at 60 MHz, 24 MHz, and 16 
MHz, respectively. The result of the emission test in a 





Semi-Anechoic chamber is shown in Figure 6. This figure 
corresponds to the emissions of the RCS with its shields 
removed. The reference line is from section 21 of 
RTCA/DO-160D environmental conditions and test 
procedures for airborne equipment. 
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Figure 6. RCS Emission Test Result 
(Shields off). 


5.5. Closed-Loop HIRF Data 

Using the data from the Semi-Anechoic chamber, 
the test plans were formed to encompass all frequencies 
within the limitations of the reverberation HIRF facility. 
During the test, the RCS was continuously exposed to RF. 
However, for any given frequency, the field strength was 
gradually stepped up, in 10-second intervals, until the 
maximum field strength was reached. The 10-second 
interval was chosen based on the rotation time of the field- 
stirrer and to allow time for visual susceptibility 
monitoring. For every test plan, the range of field strength 
for all frequencies was the same, therefore, the number of 
steps from minimum to maximum field strength was also 
the same in order to maintain consistency for all tests. 
Table 1 is an example of the first test conditions for 
continuous HIRF exposure while RCS shields were off. 


Besides unmodulated Continuous Wave (CW), the 
RCS has been exposed to Square Wave (SQW) modulated 
radiation. Preliminary data reveal a number of upset 
regions. Figure 7 shows a crashed flight. Further analyses 
of the data indicate that the crash was primarily due to 
upsets on the optical transmitters and receivers. The optical 
transmitters and receivers were shielded, and the tests were 
repeated. As a result the upset regions were eliminated. In 
Figure 7, Roll and DELAC as well as Pitch and DELEC are 
displayed together to provide visual correlation. 



Table 1. Test Conditions with Continuous 
HIRF Exposure. 


Frequency 

Min 

Max 

Recovery 

Range 

Field 

Field 


(MHz) 

(V/m) 

(V/m) 


F 

50 

250 

On 


F= {120 MHz + 60 MHz* I, 

120 MHz + 24 MHz * I, 

1 12 MHz + 16 MHz * 1} < 1GHz 

1 = 0 , 1 , 2 ,... 


Figure 7. Aileron and Elevator Commands, 
Communication Failure. 

Since the RCS recovery mechanism was not 
triggered during this test, the test range was expanded to 
cover a wider range of field strengths. However, to keep 
the number of tests and the required time the same as the 
previous test, the granularity of the field strengths was 
decreased. Table 2 is an example of the second test 
conditions for continuous HIRF exposure while RCS 
shields were off. 

Analyses of the data revealed a number of upset 
regions, Figure 8. Further analyses indicate that the upsets 





were internal to the RCS and the recovery mechanism was 
indeed initiated. 


Table 2. Test Conditions with Continuous 
HIRF Exposure. 


Frequency 

Range 

(MHz) 

Min 

Field 

(V/m) 

Max 

Field 

(V/m) 

Recovery 

F 

100 

1000 

On 


F= {120 MHz + 60 MHz* I, 

120 MHz + 24 MHz * I, 

1 12 MHz + 16 MHz * 1} < 1GHz 

1 = 0 , 1 , 2 , ... 


6. Software Fault Injection 

In order to characterize the RCS recovery scheme, 
a series of tests were conducted in which faults were 
introduced to the RCS by setting the appropriate flags that 
would trigger the RCS recovery mechanism. Using the 
GUI-based software and in the absence of HIRF, faults 
were injected into the RCS at specific times. These tests 
were concentrated on four regions of flight: before glide 
slope engagement, at and in the vicinity of glide slope 
engagement, after glide slope engagement, and approaching 
the runway. 


7. RCS Performance Measures 



Figure 8. Aileron and Elevator Commands 
(DELAC and DELEC), HIRF-induced Fault. 

Although the RCS recognized the faults and its 
recovery mechanism was triggered, it is difficult to 
determine the exact cause or component responsible for the 
failure because of the limited accessibility inside the RCS. 


Analyses of the collected data from the software fault 
injection tests reveal that the RCS recovery mechanism 
takes about 360 ms to complete, while on the average it 
takes about 30 seconds for the airplane flight attitude to 
return to normal. The analyses further reveal that the RCS 
and airplane attitude recovery times are independent of the 
flight mode. A closer look at the response of the Aileron 
Command (DELAC) for the case of a software injected 
fault from prior to fault injection and until after the RCS 
internal recovery process is depicted in Figure 9. As shown 
in Figure 9, the flight continued for the duration of the RCS 
recovery using the old values. Upon recovery, however, 
abrupt command output transitions upset the flight attitude, 
which in turn takes approximately 30 second to correct. 
These performance measures correlate to the measured 
values for the case of HIRF-induced faults, Figure 8. 


RCS Recovery: Fault Injected at Frame 2560 



Figure 9. RCS Recovery Triggered. 

Another set of tests was conducted to further 
observe the effects of communication errors on the RCS 
recovery scheme. For these tests, communication lines to 
the RCS were disconnected and reconnected for various 





time delays. Regardless of the duration of the 
communication breakdown and upon reestablishing 
communication, the flight continued with minor 
interruptions in the control laws and airplane attitude. 
Figure 10 is an example of a communication breakdown of 
one-second duration. Since the RCS recovery mechanism 
was not triggered, this observed response is most likely due 
to the natural behavior of the control laws and the airplane 
simulation, and probably had little to do with the special 
internal mechanisms of the RCS. 



Figure 10. Communication Interruption of 
One Second. 

Comparison of the behavior of the system during a 
HIRF induced fault to that of a communication breakdown, 
Figures 8 and 10, respectively, reveals that internal faults 
have noticeable effects on the performance of the RCS. 
Furthermore, the fault injection experiments seem to 
confirm this finding. Questions arise as to whether this is 
due to implementation of the control laws in the RCS, the 
backup mechanism of the airplane states, the recovery 
procedure, or the hardware limitation of this prototype. The 


search for answers to these questions will help direct future 
plans for this work. 


8. Summary 

The design and development of a Closed-Loop 
System to study and evaluate the performance of the 
advanced RCS architecture when subjected to EME is 
presented. The integration of this hardware proved to be a 
major undertaking. During this process a number of bugs 
in the 737-control law implementation of the RCS were 
found that are being resolved. In support of this Closed- 
Loop System, a Windows-based software package was 
developed to handle the time critical communication of data 
and commands between the RCS and flight simulation 
code, in real-time while meeting the stringent hard 
deadlines. This package consists of an ARINC429 bus 
driver, flight simulation code and GUI-based displays of the 
key elements of the control laws, as well as the airplane 
attitude. As a result, this package enables the researchers to 
monitor all activities of the airplane during the flight in real 
time. The real-time capability of this package is crucial 
during the EME testing of the hardware. The upset 
recovery scheme of the RCS is characterized and 
performance of the RCS under various conditions is 
discussed. 
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